-
-
Notifications
You must be signed in to change notification settings - Fork 14k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support external bootloader backends (RFC-0125) #172237
Conversation
I hope this isn't too out-of-scope, but I think it may be a good idea to add some fields to bootspec for secure boot certificates/keys as well as a field for a hash of the current system closure for a TPM to verify against. Perhaps even some fields for kernel, bootloader, and any related hashes we could stick in a TPM and verify against, that aren't already included in the nixos system closure. (eg. kernel, bootloader, etc on /boot as ESP partition) |
This is definitely out of scope for bootspec, as those are configuration options that apply to the bootloader installation tool, and are highly policy-driven. Note that the RFC specifically mentions SecureBoot. Indeed, I have implemented secureboot against bootspec.
These may be useful fields, though I omitted them because those can be safely derived by the bootloader installation tool. For that reason, I'm not sure they should be included in the spec. This may be worth discussion in NixOS/rfcs#125.
This is one of the very reasons it isn't appropriate to make those keys part of the system's closure: the policy of which keys and when they rotate is infinitely variable, and these parameters are very likely independent of a specific system closure. Embedding this information into the bootspec encodes policy which shouldn't be encoded. As an aside, I didn't want to put too much of a point on it but: we worked on bootspec for precisely this reason: making SecureBoot work for different use cases. |
Yeah, that's why I was thinking it may be out-of-scope, I was thinking we might be able to use bootspec as a standardized way to either forward some information to different bootloaders or use it for gathering information to implement such a scheme for verified boot.
Okay, that's something I misunderstood. I didn't realize the bootspec document is part of the closure itself, in which case that throws my idea completely out, since we then can't guarantee things, thus ruining the entire point. |
nixos/doc/manual/from_md/configuration/bootloader-external.section.xml
Outdated
Show resolved
Hide resolved
There's a small bug when using this on systems with no initrd, like nixos-on-wsl:
|
nixos/doc/manual/from_md/configuration/bootloader-external.section.xml
Outdated
Show resolved
Hide resolved
This allows supporting external bootloader backends.
…n's bootspecs into the parent See: NixOS/rfcs#125 (comment)
This does the following: * turns bootspec into a NixOS module * validates bootspecs with Cue * exposes internal knobs
This will test various scenarios of bootspec generation.
…otspec when bootspec is enabled
We separate the different steps (injecting the toplevel and injecting the specialisations) so that it's easy to document what each snippet is actually doing.
The documentation is generated thanks to `meta.doc`, and was out of date anyways.
The bootspec package provides synthesis and validation tooling for RFC-0125 compliant bootspec documents.
As this is a PR guarded by an experimental flag and multiple tests and one which is in good shape, I think I can self-merge it in the next days once the GRUB fix is landed. Plus, it is easy to revert and enable developers to test SecureBoot (and more!) properly. |
warnings = [ | ||
''RFC-0125 is not merged yet, this is a feature preview of bootspec. | ||
The schema is not definitive and features are not guaranteed to be stable until RFC-0125 is merged. | ||
See: | ||
- https://github.com/NixOS/nixpkgs/pull/172237 to track merge status in nixpkgs. | ||
- https://github.com/NixOS/rfcs/pull/125 to track RFC status. | ||
'' | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no native way to turn this rather annoying warning off other than introducing another option?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An other way to turn it off is to merge RFC-0125 :)
Description of changes
Experimental implementation of NixOS/rfcs#125.
To do:
Not planned to be part of this PR:
Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)nixos/doc/manual/md-to-db.sh
to update generated release notes